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SECTION 1 
INTRODUCTION 


1.1 PURPOSE 

The purpose o£ the Mission Control Center (MCC) /Shuttle Test Plan 
is to define the entire MCC/Shuttle testing activity from develop 
ment through operations to a level of detail which will support 
the National Aeronautics and Space Administration (NASA] and con- 
tractor management in the following areas : 

A. Test Management . Provide the definition and guidelines 
that will ensure that all systems are tested to the proper 
level throughout the development and operations phases. 
This test plan will provide the planning tool to ensure 
that the test program is conducted in a consistent manner. 

B. Test Tool Development . Provide the planning and defini- 
tion at an early date to ensure that the test tools being 
developed will support the required tests, that redundant 
tools are not being developed by the different contrac- 
tors, and that commonality between tests through various 
stages of the development and operations phases is maxi- 
mized to minimize test tool costs. 

C. Resource and Schedule Planning . Provide a projection of 
required resources and schedules which lead to a feasible 
MCC/Shuttle test program. 

1.2 SCOPE 

The MCC/Shuttle Test Plan governs all testing, including factory 
testing, for both the development and operations phases. Volume 
I specifies the levels of testing required and their interrela- 
tionships. 
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1.3 ORGANIZATION 

The MCC/Shuttle Test Plan is composed o£ six volumes: 

• Volume I, Philosophy and Guidelines 

• Volume II, Development Testing, Aeronutronic Ford Corpora- 
tion 

• Volume III, Development Testing, International Business 
Machines Corporation 

• Volume IV, Software Reconfiguration Testing 

• Volume V, Validation Testing 

• Volume VI, Maintenance Testing. 

The purpose and content of each of these volumes is addressed in 
this volume. Appendix A defines acronyms used throughout this 
test plan. Appendix B contains definitions of terms applicable 
to Volume I. 

1.4 APPLICABLE DOCUMENTS 

• JSC-10013A (DRL 7) , Mission Control Center (MCC) System 
Specification for the Shuttle Orbital Flight Test (OFT) 
Timeframe 

• JSC-10106 (DRL 27), Mission Control Center Operational 
Configuration Document 

• JSC-10099 (DRL 44), Mission Control Center Shuttle Mainte- 
nance Plan 

• JSC-10105 (DRL 50), M^O Standard Operating Procedure 

• JSC-10102 (DRL 47), M^O Operations Plan 

• JSC-10081 (ERL 11), Interface Definition Document 
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• PHO-TR388, PHO Quality/Reliability Plan 

• SISO-EX140, System Engineering Standard 

• SISO Standards (Volume III) 

• JSC-11026, Project Implementation Plan 

• JSC-11024, GBSS Test Plan 

• JSC-10952, GBSS Management Plan 

• JSC-11044, QA Plan 

f JSC-10972, QA Procedures 

• JSC-11400, Programmer's Guide 

• DRL 4, SDPC Test Plan. 
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SECTION 2 

TESTING PHILOSOPHY 


2.1 PHILOSOPHY 

The basic philosophy for the MCC/Shuttle testing is to establish 
an integrated test program for all system and subsystem level 
testing required during the MCC/Shuttle timeframe. The goal of 
this program is to provide effective and timely testing to demon- 
strate compliance to hardware/software specifications and mission 
support requirements. MCC/Shuttle testing consists of two phases: 

• Development Testing Phase . Includes predelivery testing, 
onsite fiardwar e/so ftw^re certification, and integration 
testing 

» Operational Testing Phase . Includes reconfiguration testing, 
validation testing, and maintenance testing. 

Detailed descriptions of these tests and test phases are provided 
in sections 3 and 4. 

The following groundrules and guidelines will be adhered to 
throughout the development of the test plan and testing of the 
MCC Shuttle System. 

Hardware . Qualification testing of hardware includes 
certification of all interfaces in addition to certifica- 
tion of all required functions. Interfaces are tested as 
a part of these qualification tests (QT's). 

B. Computer Systems (Hardware and Operating Systems) . Accept- 
ance testing includes all interfaces and drives end items 
through the operating systems access methods. 

C. Applications Programs . Applications programs interface 
with logical end items as a part of their test plans. An 
example is the Shuttle Data Processing Complex (SDPC) driv- 
ing the Network Output Multiplexer (NOM) as a part of de- 
velopment testing. 
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D, String Testing . Minimum string buildup is planned based 
upon the preceding guidelines. String tests are related to 
major functions (i.e., telemetry data flow) and will essen- 
tially be a data flow test with predefined data sources. 

The primary objectives are to assemble large elements of 
the MCC into a system level flow and exercise specific func- 
tions which were not thoroughly checked during development 
testing, 

E, Validation Testing . This test phase is primarily for 
operations familiarization and confidence. Minimum in- 
ternal validation testing should be planned. Advantage 
should be taken of other testing activities going on 
within the MCC to assure that minimum system time is re- 
quired for this activity. 

F, External Validation . External validation is essentially 
the classical approach but includes an increased emphasis 
on integration of the mission simulations into the MCC, 
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2.2 APPROACH 

To meet the guidelines and goals established, a test plan for 
each of the applicable test disciplines will be developed 
which specifies ; 

• Guidelines 

• Objectives 

• Procedures 

e Documentation requirements 

• Identification of tests to be performed 

• Test tools required 

• Responsibilities 

• Brief description of each test. 

The MCC/Shuttle Test Plan provides the baseline from which the 
detail test design and test efforts will he accomplished. The 
philosophy, scope, and content of Volumes II through VI are de- 
fined in this document. 
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SECTION 3 

DEVELOPMENT TESTING 


3.1 PHILOSOPHY 

Development testing encompasses all testing performed during the 
MCC/Shuttle implementation. This includes predelivery testing, 
onsite hardware/ software certification or recertification testing, 
and onsite integration testing. Figure 1 illustrates the develop- 
ment testing process. 

3.1.1 Predelivery Testing . Predelivery testing includes those 
tests that are performed at the contractor facility prior to 
installation onsite. The testing that is performed includes: 

• Space Information Systems Operation (SISO) , hardware accept- 
ance tests (AT's) 

• SISO software development testing 

• IBM/SDPC software operating system development and prede- 
livery testing 

• IBM/SDPC hardware predelivery testing. 

Software tests may be performed at the factory or onsite depending 
on computer availability. 

3.1.2 Certification Testing . Hardware/ software certification 
testing includes those tests that are performed in an operational 
environment onsite to certify and selloff to NASA the deliverable 
hardware/software components. The testing that is performed in- 
cludes ; 

• SISO, hardware QT's 

• SISO, hardware modification requalification tests (RT’s) 

• SISO, software QT 
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Figure 1 MCC Test Flow Diagram 
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• SISO, subsystem QT 

• IBM/SDPC, hardware/operating system software onsite AT 

• IBM/SDPC, subsystem integration testing 

• IBM/SDPC, performance testing 

• IBM/Ground-Based Space System CGBSS) application software 
development testing 

• IBM/GBSS, software independent verification testing. 

3.1.3 Integration Testing . Integration testing includes those 
tests that are performed to verify end-to-end application of all 
MCC/Shuttle hardware/ software elements. The primary objective 

is to assemble large elements of the MCC into application strings 
such as telemetry and command and verify that they meet opera- 
tional requirements. 

3.1.4 Recertification Testing . The philosophy governing recer- 
tification testing is currently being developed and will be 
included at a later date. 

3.1.5 Test Responsibility . Predelivery testing and onsite 
hardware/software certification testing is the responsibility 
of the system manager of SISO and IBM responsible for designing 
and implementing the hardware and/or software. These tests in- 
clude the testing of the particular deliverable hardware and its 
immediate interfaces. Integration testing is the responsibility 
of the Test and Checkout Section of SISO Engineering Integration 
Department. 
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3.2 APPROACH 

Development testing covers all phases of testing starting with 
predelivery and culminating with the application string tests. 

A test plan is required to satisfy MCC/Shuttle development test 
goals and ensure an orderly process of specif ication- oriented 
testing. 

The Development Test Plan is contained in two volumes. Volume II 
is the responsibility of Test and Checkout Section of SISO, sup- 
ported by the Equipment Engineering Department, the Computer 
Systems Department, and the Software Systems Department. Volume 
II addresses all subsystem and systems integration tests. The 
predelivery and certification of the SDPC subsystem is contained 
in Volume III, and is the responsibility of IBM Corporation. 

3.2.1 Scope . The scope of the Development Test Plan includes 
plans for each hardware/software subsystem plus all integration 
testing required to ensure that all requirements of performance 
specifications are satisfied. 

3.2.2 Contents . The Development Test Plan (Volumes II and III) 
contains at a minimum the following information: 

• Detail test philosophy and guidelines 

• Documentation requirements; discrepancy reports (DR’s), 
test procedures, test reports, etc. 

• Test sequence 

• Identification of each test or logical groups of tests to be 
performed. 

Each test identified is then addressed with the following informa- 
tion: 

* 

• Test number 


• Test title 


JSC-10309 


Test objective 
Test tools required 

Test configuration (simple block diagram) 

Test dependencies (identify prerequisites for the test 
such as hardware/ software availability and completion of 
test X or Y) 

Brief description of each test 

Test data scoring method (printer output, visual readout, 
etc. 


Support requirements (MSA, SISO M§0 and Operations Support, 
IBM, etc. ) , 
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SECTION 4 

OPERATIONAL TESTING 


4.1 PHILOSOPHY 

Operational testing is performed to demonstrate the operational 
readiness of the MCC to support specified missions. These tests 
include software reconfiguration, validation, and maintenance. 

4.2 SOFTWARE RECONFIGURATION TESTING 

Software reconfiguration tests are designed to certify that recon- 
figurable software tables are configured to appropriate user re- 
quirements, Examples of these tests are Telemetry Preprocessor 
Computer (TPC) tables that define telemetry downlink formats. 
Institutional Data Systems Division (IDSD) computer- compatible 
tape (CCT) , analog event drivers (AED) output buffers, SDPC out- 
put buffers, etc. 

4.2.1 Approach . Prior to using the application software for 
validation testing, it is necessary to verify that software tables 
have been configured to requirements. These tests are performed 
on an as necessary basis dependent on the number/degree of changes 
to the software tables required to support mission operations. 

The test plan necessary to satisfy these goals is the responsi- 
bility of the Test and Checkout Section of SISO with support of 
the Independent Verification Group of IBM. 

4.2.2 Scope . The Software Rsyconfiguration Test Plan (Volume IV) 
includes plans for testing all reconf igurable tables for both the 
TPC and SDPC software. 

4.2.3 Content . The Software Reconfiguration Test Plan contains 
the following minimum information; 

• Detail test philosophy and guidelines 

• Procedural and documentation requirements 
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• Test sequence 

• Identification of types of tests to be performed. 

Each type identified is addressed with the following information: 

• Test number 

• Test title 

• Test objective 

• Test tools required 
t Test configuration 

• Test dependencies 

t Brief description of each test type 

• Test data scoring method (printer output, visual readout, 
etc.) 

• Support requirements (NASA, SISO, IBM). 
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4.3 VALIDATION TESTING 

Validation testing includes verifying the operational capability 
of the MCC internal system, the MCC/Simulation interface, and the 
MCC/Spacecraft Tracking and Data Network (STDN) systems inter- 
faces. These tests also verify that configurations and procedures 
satisfy user requirements in a mission specific atmosphere from 
the remote site to the user end instrument. Operational valida- 
tion testing is accomplished as follows: 

A. Internal validation tests are performed to test internal 
functions, and provide operations familiarization and con- 
fidence. 

B. MCC/Shuttle Mission Simulator (SMS) validation tests are 
accomplished utilizing the SMS and simulation computers. 

All defined mission configurations are tested. This 
demonstrates the ability to support premission simulated 
flights and establish the readiness of the MCC systems to 
support external validation testing. 

C. External validation provides the testing of MCC systems 
with external systems at White Sands (WHS) /Tracking Data 
Relay Satellite System (TDRSS) , Western Test Range (WTR) , 
John F. Kennedy Space Center (KSC) , Goddard Space Flight 
Center (GSFC) , the Ground Spacecraft Tracking and Data 
Network (GSTDN) stations, landing sites, and remote Pay- 
load Operations Centers (POC's). In application, these 
interfaces are proven incrementally with the major task 
being the data acquisition, recovery, and processing 
involving the GSTDN and the MCC interface. 

The overall configurations for MCC/Shuttle requires extensive 
testing and verification subsequent to respective deliveries. 

After initial validation, only abbreviated tests are required 
for flights which follow. 
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4.3.1 Approach . Validation tests are performed in an operational 
configuration to demonstrate the operational readiness of the 
complete system for a specified mission. The test plan is gen- 
erated to satisfy the MCC/Shuttle validation test goals. The 
Validation Test Plan (Volume V) is the responsibility of the SISO 
Operations Support Department. 

4.3.2 Scope . Volume V addresses the testing following integra- 
tion tests that are performed to assure MCC/Shuttle readiness 
for specified mission configurations. 

4.3.3 Content . The Validation Test Plan contains the following 
minimum information; 

^9 Detail test philosophy and guidelines 

• Documentation requirements (DR's, test procedures, test 
reports, etc.) 

• Test sequence 

• Identification of each test to be performed. 

Each test identified is then addressed with the following informa- 
tion: 

• Test number 

• Test title 

• Test objective 

• Test tools required 

• Test configurations (simple block diagram) 

• Test ^dependencies (identify prerequisites for each test 
such as hardware/software availability and completion of 
test X and Y) 

• Brief description of each test 
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• Test data scoring method (printer output, visual readout, 
etc.) 

• Support requirements (NASA, SI SO, IBM) . 
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4.4 MAINTENANCE TESTING 

The maintenance testing ensures that the MCC/Shuttle is in a state 
of Operational readiness to support scheduled user requirements. 
This is accomplished by implementation of a preventive and cor- 
rective maintenance program that ensures equipment availability 
for operational support. The maintenance program is followed 
with internal M§0 validation tests to verify that the MCC/Shuttle 
is configured to the current released version of JSC-10106, Mis^ 
sion Control Center Operational Configuration Document . These 
tests also verify that each unit, subsystem, and system is in a 
state of operational readiness, 

4.4.1 Approach . Maintenance testing consists of the maintenance 
program and maintenance validation testing. These activities are 
performed by the SISO M60 Department. 

A. Maintenance Program . The maintenance program is established 
by JSC-10099, Mission Control Center Shuttle Maintenance 
Plan, The Maintenance Plan identifies equipment to be 
maintained, establishes a preventive and corrective main- 
tenance program, provides levels of maintenance coverage, 
and defines reporting procedures. The plan also estab- 
lishes standard maintenance procedures outlining policy 

and guidelines for all maintenance activities. 

B. Maintenance Validation Testing . Maintenance validation 
testing performed by M§0 personnel is directed by JSC-10105, 
M&O Standard Operating Procedure y established by JSC-10102, 
M&O Operations Plan, The validation test procedures are 
developed by M^O and compiled into the MCC Validation 

and Test Manual, Volume II, The internal M^O Validation 
tests are conducted in accordance with standard operating 
guidelines, MCC reconfiguration schedules, and support 
count sequences directing specific validation tests; 
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4.4.2 Scope . Volume VI addresses maintenance activities and 
validation tests performed by MSO in verifying the operational 
readiness of the MCC/Shuttle to support scheduled users. 

4.4.3 Contents . The Maintenance Test Plan identifies preventive 
maintenance instructions and validation tests and includes the 
following information: 

A. Preventive Maintenance Instruction (PMI) Format 

• PMI identification 

• Interval of occurrence 

• Equipment affected 

• Manpower requirements 

• Time for completion 

• Tools and test equipment required 

• Cleaning and inspection instructions 

• Functional test instruction. 

B. Maintenance Validation Test Format 

• Validation test number 

• Test title 

• Test description 

• Scheduling requirements 

• Equipment/equipment groups to be tested 

i 

• Support equipment and software requirements 
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Supporting documentation 

Test data/test report disposition 

Test procedure. 
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APPENDIX A 
ACRONYMS 


AT 

ATP 

BITE 

DR 

DRL 

GBSS 

GSFC 

GSTDN 

IBM 

IV 

KSC 

MCC 

NASA 

NOM 

OFT 

PM I 

POC 

QT 

QTP 

RT ' 

SDPC 

SISO 

SMS 

STDN 


Acceptance Test 

Acceptance Test Procedure 

Built-in Test Equipment 

Discrepancy Report 

Data Requirement List 

Ground-Based Space System 

Goddard Space Flight Center 

Ground Spacecraft Tracking and Data Network 

International Business Machines Corporation 

Independent Verification 

John F, Kennedy Space Center 

Mission Control Center 

National Aeronautics and Space Administration 

Network Output Multiplexer 

Orbital Test Flight 

Preventive Maintenance Instruction 

Payload Operations Centers 

Qualification Test 

Qualification Test Procedure 

Requalification Test 

Shuttle Data Processing Complex 

Space Information Systems Operation 

Shuttle Mission Simulator 

Spacecraft Tracking and Data Network 


ACRONYMS CCONT'D) 


TDRSS 

Tracking Data Relay Satellite 

TPC 

Telemetry Preprocessor Computer 

TPS 

Test Preparation Sheet 

WHS 

White Sands 

WTR 

Western Test Range 
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APPENDIX B 
DEFINITION OF TERMS 


B.l Development Testing Phase . The development testing phase o£ 
software or hardware testing is performed during MCC/Shuttle 
development beginning with factory testing of discrete hardware/ 
'Software modules, progressing through specification-oriented test- 
ing, e.g., AT's, QT's, RT's, and ending with the final MCC/Shuttle 
integration test. 

B.2 Software Development Test (SISO) . Development testing en- 
compasses all testing performed during an application’s develop- 
ment phase. Beginning with the testing of the application con- 
trol type programs, the procedure follows requirements-oriented 
testing of each function before and after it is incorporated into 
the current version of the subsystem. 

B.3 Software Development Test (IBM) . Development testing encom- 
passes all testing performed during an application's development 
phase. Beginning with the testing of the application control 
type programs, the procedure follows requirements-oriented test- 
ing of each function before and after it is incorporated into the 
current version of the subsystem. This procedure continues until 
all elements of the application software are tested together, 
then it is delivered to the Independent Verification (IV) group 
as the final system release. 

B . 4 Software Acceptance Test (SISO) 

A. Purpose . The AT is comprised of tests which verify a 
software entity has been constructed and implemented in 
accordance with applicable design specifications. A 
software entity may be a unit (one program) , a module or 
subsystem (a collection of programs), or a complete soft- 
ware system (all programs in all modules). The AT demon- 
strates that all elements of the software satisfy the 
performance criteria as specified by an approved AT pro- 
cedure. An AT is used with vendor supplied software, soft- 
ware developed at other than the using facility prior to 
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shipment, and software which cannot be tested in its opera- 
tional environment due to factors such as phased delivery 
schedule , 

B, Test Procedure . An AT procedure specifies the inspections, 
tests, and criteria to ensure that the design requirements 
for the configuration change or product to be delivered 
have been fulfilled. The criteria should consist of 
acceptable test results and include measurement and toler- 
ance values. An AT procedure may be prepared for a single 
equipment component/computer program item, a subsystem, or 
a system. 

B .5 Hardware Acceptance Test (SISO) 

A. Purpose . Hardware acceptance testing certifies the equip- 
ment has been manufactured according to applicable docu- 
ments and the equipment meets major performance require- 
ments as per applicable specifications. Successful comple- 
tion of the AT and associated signatures constitutes au- 
thorization to ship elements to the designated location. 

B. Scope . Hardware acceptance testing is normally conducted 
upon completion of manufacturing and assembly of the hard- 
ware and prior to site delivery. The AT is performed at 
the manufacturing facility on a hardware element that is 
generally defined as a' module unit , subsystem component, 
or subsystem. The AT demonstrates that all elements of 
the hardware satisfy: 

1. Manufacturing and assembly standards in accordance with 
applicable engineering documentation and standards; 

• QA inspection of workmanship of each manufactured 
item and of related documentation 

• Engineering verification that the manufactured item 
is in accordance with applicable documentation. 

2. Functional performance specifications to the extent of 
the reasonable testing capabilities available in the 
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manufacturing facility. This testing should include 
the following; 

• Verification of internal functions 

• Verification of data throughput 

• Verification of interface control logic levels and 
timing including interface connector pin assign- 
ments 

• Power requirements 

• Verification that design implementation is in accor- 
dance with applicable specifications. 

C. Test Procedure . The AT is conducted according to an 

approved acceptance test procedure CA-TP) . The ATP con- 
tains , as a minimum, the following (reference SISO Stan- 
dards, Volume III, Part 5.1): 

1. Identification of the item to be tested. 

2. Test objectives. 

3. Specification of required test resources (test equipment/ 
software) and calibration reference. 

4. Identification of testing tools/methods such as: 

• Built-in test equipment (BITE) 

• Test software (when the element has a computer 
interface) 

• Other test equipment to simulate an interface. 

5. Step-by-step test procedures including initial setup. 

6. Pass or fail criteria for the test. 
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7. Specified operational tolerances. 

8. Data sheets that record specific values. 

9. Signoff forms. 

ATP's are type 1 documentation. The ATP is approved by the appli- 
cable SISO engineering department, Quality Assurance Department, 
and the Program Management Office, as specified in the SISO 
Standards (Volume III, part 5.4). The ATP is submitted to NASA 
for review at least 30 days prior to the scheduled AT. 

B.6 Predelivery Test (IBM) . Predelivery testing is that testing 
to be conducted at the IBM facility in Nassau Bay on SDP2 to 
demonstrate the capabilities of each hardware element type, and 
the capabilities of the operating systems software, and support 
software. 

B.7 

Purpose . A QT verifies the functional capability of new 
equipment computer programs following onsite development 
or installation. The test consists of a series of tests 
that combine the various elements of a software system in- 
to a complete operational entity and verifies performance 
against established requirements as delineated in the de- 
sign specification. Successful completion of the QT con- 
stitutes delivery and acceptance of the software product 
by the customer. 

B. Test Procedure . The QT is conducted according to an ap- 
prove(J quaTlif ication test procedure (QTP) . The QTP pro- 
vides detailed documentation of all testing required to 
demonstrate the software is in compliance with all appli- 
cable specification requirements. The procedures will 
contain, as a minimum, the following: 

• Identification of system element to be tested 

• Test ob j ective 
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• Resources required for the test 

• Step-by-step procedure for accomplishing the test, in- 
cluding the initial settings for all manually controlled 
parameters 

• Specification of testing tools/methods such as test 
software 

• Criteria for passing or failing the test 

• Specified tolerance of operation. 

B. 8 Hardware Qualification Test (SISO^ 

A. Purpose . The QT certifies the equipment performs in its 
operational environment as required by the applicable speci 
fication. Successful completion of the QT constitutes de- 
livery and acceptance of the element tested. 

B. Scope . Hardware qualification testing is conducted to 
verify the functional capability of an element (unit, sub- 
system, or system) which may consist of any combination 

of hardware and software components. The QT also demon- 
strates to the customer that the element performs to speci- 
fication. Successful completion of QT and associated 
customer signoff constitutes acceptance by the customer. 

The QT (which may be a series of tests) evaluates the com- 
plete element (including interfaces) as an entity in its 
operational environment. The QT is normally performed at 
the delivery site to verify: 

1 . Operational Capabilities 

• All internal functions perform to specification 

• Required data throughput can be accomplished 

t Interfaces with external equipment are operational 

• Operator interface controls 

• System response time meets operational requirements. 
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2. Onsite Workmanship . Verification is accomplished by; 

• Installation inspection by QA 

• Inspection of cable routing and connectors 

• Verification of installation integration (equipment 
interface inspection, etc.). 

3. External Equipment Interfaces . The following items 
constitute verification: 

• Verification to appropriate specification 

• Identification of interface tests which are being 
waived (and/or allocated to other system element 
tests). 

4. System Integrity . Demonstrated by: 

• Error rates within specified limits 

• Verified operation during failure mode conditions 

• Ability to function properly with other interfaced 
sys terns , 

C, Test Procedure . The QT is conducted according to an ap- 
proved qualification test procedure (QTP) . The QTP pro- 
vides detailed documentation of all testing required to 
demonstrate that the equipment is in compilance with all 
applicable specification requirements. The procedures will 
contain, as a minimum, the following: 

1. Identification of system element to be tested. 

2. Test objective. 

3. Resources required for the test (e.g., test equipment 
for software test tapes, etc.). 
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4, Step-by-step procedure for accomplishing the test, in- 
cluding the initial settings for all controls, power 
supply voltages, etc. 

5, Sficcif ication of testing tools/methods such as: 

• BITE 

• Test software (when the element has a computer in- 
terface) 

6, Criteria for passing or failing the test. 

7, Specified tolerance of operation. 

QTP's are type 1 documentation and will be prepared in accordance 
with SI SO Standards (Volume III, Part 5.1). The QTP is appro' d 
by the applicable SISO engineering department. Quality Assurance 
Department, and Program Management Office, as specified in the 
SISO Standards (Volume III, Part 5.4). The QTP is submitted to 
NASA for review at least 30 days prior to the scheduled QT. 

B, 9 Hardware Requalification Test (SISO) 

A. Purpose . An RT is used to verify the functional capability 
of a previously certified equipment item following the 
incorporation of a modification which expands or reduces 
the capacity/capability of the existing design or system. 
Depending onthe equipment involved, the RT requirement 
may be satisfied by PMI’s, continuity checks, tests using 
specialized test sets, or by an operational demonstration 
with associated subsystem elements. An RT may or may not 
require onsite computer support. 

B. Test Procedure . The writing of requalification test pro- 
cedures (RTP's) is the responsibility of the SISO engi- 
neering organization that performed the system design. 

RTP's may, depending on test requirements, consist of a 
detailed test procedure, or simplified test procedure. 

RTF's are considered type 1 documentation, and as a mini- 
mum will be approved by the. .applicable SISO engineering. 
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Program Management Office, and Quality Assurance organi- 
zations, All RTF’s will be submitted to NASA for review 
at least one week prior to the scheduled test. Concur- 
rently, copies will be given to M^O for their review and 
familiarization prior to the scheduled test. 

B,10 Test Preparation Sheet CSISO) . When an equipment modifica- 
tion is installed which is relatively minor in nature, a test 
preparation sheet (TPS) may be used, SISO has the prerogative 
of describing the simplified tests for a minor modification 
required fgr QA and customer approval on a TPS. The* TPS is 
a NASA form, MSC Form 1225. These forms can be used with SISO 
QA concurrence to cover minor testing efforts such as; 

t Workmanship inspection 

• Referencing M§0 PMI checks which will suffice for checkout 

• Simple cable or circuit continuity checks 

• Simple type test procedures requiring a minimal number of 
steps and observations. 

B.ll Software Requalification Test CSISO^ 

A, Purpose . An RT is used to verify the functional capability 
of a computer program following the incorporation of a 
modification. The RT requirement may be satisfied by 
tests using specialized test data sets, or by an opera- 
tional demonstration with associated subsystem elements. 

B. Test Procedure . The RTP is the basis for the RT. As with 
the QTP, it describes the goals of. the tests, the resources 
necessary to test the changes, the detailed test pro- 
cedures, the responsible organizations, and the success 
criteria for the test, 

B.IZ Onsite Acceptance Test [IBM) . Onsite acceptance testing is 
conducted at JSC to demonstrate the capabilities of hardware ele- 
ments delivered by IBM and to prove the software deliverables 
perform to contract specifications. The software testing demon- 
strates the SDPC Benchmark Program Test on each of the computer 
systems to be delivered. 
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B,13 System Integration Test CIBM) . System integration, testing 
is con^ucte^ atJSC to demonstrate the capability o£ the SDPC to 
communicate with the MCC support systems through the SDPC to MCC 
equipment interfaces. 

B.14 Performance Test (IBM] . Performance testing is conducted 
after system integration testing to demonstrate the operational 
speeds and data handling capabilities of the SDPC while inter- 
faced to the MCC equipment in the operational configuration. 

B.15 Integration Test (SISO) . Integration testing is performed 
with each application string such as telemetry, command, trajec- 
tory, etc., to verify that the application string meets system 
performance requirements. 

B.16 Independent Verification Independent verification 

(IV) testing is an independent, requirements-oriented approach 
to testing in a complete system environment (all software com- 
ponents have been incorporated into the system) . IV performs 
detailed software interface tests between the various applica- 
tions, as well as mission operations computer/dynamic standby com- 
puter interface tests, timing interference tests, final performance 
measurement tests, and independently defined requirements-oriented 
system level functional testing. Complete control of software 
modifications is an integral part of the IV process. The soft- 
ware configuration management continues into the post -delivery 
timeframe with detailed testing of modifications and extensive 
regression testing. 

B, 17 Operational Testing Phase . The operational testing is per- 
formed with the complete end-to-end system in an operational 
configuration. The testing is performed with and by users of 
the system utilizing tests based upon operational functions. 

B,18 Reconfiguration Test (SISO) . Reconfiguration testing con- 
sists of a test or a series of tests which are performed to verify 
a hardware/software table change. These tests are ongoing and 
are required prior to incorporation of the change into the opera- 
tional system to verify the change and the effect of the change 
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on the integrity o£ the MCC/ Shuttle .system-. Examples of items 
which consistently require reconfiguration testing are; 

• Software . Tables that define telemetry preprocessor 
computer telemetry downlink formats, Institutional Data 
Systems Division, computer-compatible tape, analog event 
drivers, output buffers, and SDPC output buffers, etc, 

• Hardware . Analog event drivers configuration changes. 

B.19 Validation Testing . Validation testing is a phase of test- 
ing to verify mission configurations. Validation test configura- 
tions are divided into three integrated hardware/software systems 
categories: 

• MCC 

• MCC/ SMS 

• MCC/STDN. 

The tests are performed in an operational configuration to demon- 
strate the operational readiness of the complete system for a 
specified mission. 

B.20 Maintenance Testing . Maintenance testing and checkout 
consists of a continuous testing phase to start after qualifica- 
tion and/or requalification of hardware/software units, subsystems 
or systems. Categories of maintenance testing are as follows: 

A. Preventive Maintenance Testing . Preventive maintenance 
testing and checkout is based on the requirement to test 
hardware for both electrical and mechanical performance 

in order to detect substandard conditions prior to failure. 
This testing requires special test software checkout hard- 
ware packages. 

B. Hardware Functional Unit Level Testing . Hardware unit 
level testing is test and checkout of a single functional 
unit to specification. A functional unit may be one or 
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more collective functions of a subsystem or a standalone 
unit of hardware. Testing at this level requires special 
software checkout hardware or hardware test equipment. 

C. Hardware Subsystem Level Testing . Hardware subsystem 
level testing consists of test and checkout to measure 
collective performance of a subsystem. Testing at this 
level requires special software checkout hardware or hard- 
ware test equipment. 

D. Hardware System Level Testing . Hardware system level 
testing consists of test and checkout to measure performance 
of all hardware within a system. This may be a sequence 

of tests using special software and/or hardware test 
equipment. 



